Date: Fri, 4 Mar 94 04:30:19 PST 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #58 

To: Ham-Digital 


Ham-Digital Digest Fri, 4 Mar 94 Volume 94 : Issue 58 


Today's Topics: 
Errors in TNC2 firmware??? 
IM_Mac1.0b27y.sea.hgqx.text 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 28 Feb 94 06:25:08 GMT 

From: nprdc!ihnp4.ucsd.edu!ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net! 
agate! library.ucla.edu!csulb.edu!tern.csulb.edu!usenet@network.ucsd.edu 
Subject: Errors in TNC2 firmware??? 

To: ham-digital@ucsd.edu 


I have recently been experimenting with TNC2 clones and had run 
across two peculiar "bugs" in the firmware of an MFJ 1278, and 
a tiny TNC2. 


The first problem relates to when the TNC2 sends to the computer 
the "Change incoming stream" command ("|B" to switch to stream B, 
for example). It seems that when in command mode, the TNC set the 
output stream to be equal to the input stream whenever it sends 
the "cmd:" prompt (if, of course. the output stream was set to 
something else previously). So it you are in command mode in stream 
A, and send a "|b" to set the input stream to B, and press Enter, 
the tnc will respond with "|Bcemd:" to tell that the output stream 
should now ALSO be set to stream B. The problem is this: The stream 
switch is sent JUST before sending the cmd: prompt. So if you are on 
stream A in command mode, and type "|bcst<CR>" to set the input to 


stream B and get the status of all streams, the tnc will send the 
results, THEN the |B, then the new cmd: prompt. SO, the output of 
the cst request made on stream B will be sent to stream A. In fact, 
the results will show that the input stream is B, while the output 
stream is A! Of course, if you type another "cst<CR>", the results 
will be sent to the proper stream, because it has already been 
corrected. Do all TNC2's exhibit this feature? 


The second problem is more major. I seems that when I am connected 
on two streams, and send text out on the first stream, and then 
switch to the second and do nothing, all output from the tnc is 
halted. For example, if I am connected on stream A and B to two 
bbs's, and I am currently on stream A, and I send "1<CR>|B" to list 
all files on the first bbs and then switch my input to the second 
bbs, the tne will halt all output back to me. The results of the 
list command will come back to the tnc, and the tne will receive them 
all internally, but will not send them to the computer....UNTIL I 
sent something to the tnc first. (Usually I send "4ck<CR>" to enter 
and then leave command mode. This will then allow all buffered data 
to be sent to me. However, it you do not send anything to the tnc, 
it will send nothing to you. 


I have found these problems by using paket 5.1. Paket creates 

a different window for each of the tnc's streams, and pressing a 
shifted arrow key allows you to switch between the streams. When you 
do this, paKet sends a "|" and the stream identifier. Therefore, it 
is very easy to switch to another stream to view incoming data, 
without wanting to send anything, thus causing the second problem. 
And having entering a command in one window and having the output 
return in another window (the first problem) was also easily 
spotted. I have reproduced these problems using a simple terminal, 
so they are not errors with paket. 


One other note. I have also played with some Kantronics Tnc. They 

do not appear to have the lockup problem, but have an even worse 
version of the first bug. The incoming stream sent from the Kan TNC's 
is only changed when data comes in from over the air, not from 
commands. So if I am on stream A, and switch to stream B, SEND a 
<CR>, (this would fix the TNC2 problem), and start sending commands, 
the tnc never send me the stream switch command, so all the feedback 
from my commands always goes to stream A, (or whatever the last 

stream to receive over the air was). This is very frustrating when 
using paket! 


Anyone have any comments on any of this? Has anyone else experienced 
this? Any ideas for solutions? 


Byon Garrabrant KD6BCH byon@csulb.edu 


Date: 4 Mar 94 10:25:24 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: IM_Mac1.0b27y.sea.hqx.text 
To: ham-digital@ucsd.edu 


=20 
Release Notes - IM/Mac 1.0=A727y 


- The numbers in the option-about dialog are now correctly formatted 


for all 
languages. 


- Beachball cursor stops spinning immediately after finishing updatin 


g mail file 
when quitting. 


- Beachball cursor stops spinning when a system error occurs. 


- When a system error occurs, the dialog that shows has a 'MacsBug' b= 


utton when 


MacsBug is running. This will create a file called ‘crash_log' whic= 


h you need 
to send me. 


- Files with filetype 'ZSYS' and creator 'MACS' 


can no 


longer be send. They're treated as invisible files like the Finder 


does. 


- When selecting a file to send, the text inside the outlined button 


was 'Send' 


instead of 'Open' if the target was an alias to a folder. 


'VM Storage') 


- When the last item (Record) in the "Edit 'bm.rc'=C9" dialog contain= 


ed only a 


filename, a system error occured. The syntax for that line is as fo= 


llows: 


[LL:<volume>:]<folder>:]<file>]. Square brackets enclose optional ite= 


ms. 


Examples: 


:My Hard Disk:My TCP/IP Folder:spool:Archive:Sent Mail 


spool:archive:sent mail 


archive 


- Finding out if MacsBug is installed via Gestalt doesn't work. Used 
another 
method. 


- Sending a file that needs to be BinHex encoded will have its name t 
runcated to 

27 characters to make room for the '.HQX' suffix in the subject tit= 
le. The 

original file name will reappear after the BinHex decoding takes pl= 
ace at the 

receiver's end. 


- Deleted mail icon was 1 pixel too high. 


- Does stuff/unstuff of files on system 7 Macintoshes that have 'Stuf= 
fIt 

Engine=AA' (version 3.0 and higher) in the Extensions folder. Files= 
that were 

compressed/made with StuffIt, Compact Pro, AppleLink, DiskDoubler o= 
Xr 

UpdateMaker won't stuff twice. 


- Beachball cursor kept spinning when a system error occured during B= 
inHex 
encoding. 
- On popular demand: 
AX25 mail: onixk@on6éar.d#an.bel.eu 
AMPRnet: ivo@onixk [44.144.8.5] 
Internet: onixk@gg.tno.nl 
AppleLink: vanursel.ivo 


Monday, February 28, 1994 - 18:48:54 UTC 


Best 73's, es cuagn de Ivo, ON1XK @ ONG6GAR.#AN.BEL.EU [44.144.8.5] 
Wednesday, March 02, 1994 - 19:55:15 +0000 UTC 


PS (by PA2AGA) 
This version obsoletes all versions of info-mac/comm/radio-immac in t= 
he 


Sumex-Aim archives. 


The new IM/Mac has (hopefully) been uploaded to ftp.std.com, to the 


directory pub/hamradio/incoming, and to ucsd.edu, to the directory 
/hamradio/packet/tcpip/incoming. If it's not there (anymore), 
then look at /hamradio/packet/tcpip/mac. 


End of Ham-Digital Digest V94 #58 
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